A primeira coisa que desejo afirmar novamente é que ninguém te paga um centavo para você programar mas sim para resolver problemas.
Sendo assim temos outro fator a considerar que é a produtividade, quanto mais produtivo você for menor será o custo para a empresa ou melhor remunerado você poderá ser porque produz mais.
Portanto visando eficiência e produtividade podemos escolher entre 2 tipos de programação : Procedural e Orientada a objetos (OOP).
Dê cara respondo a pergunta : Qual a melhor? Resposta : Depende do projeto.
Note bem que as linguagens se dão bem mais com um tipo de programação do que com outro. Por exemplo, C# se dá melhor com OOP e Visual Basic se dá melhor com a Procedural. Contudo, depende mais da solução a ser apresentada que da linguagem a ser utilizada.
Mais conhecida como programação estruturada consiste em 'fatiar' o trabalho a ser feito pelo sistema em diversas partes funcionais bem simples.
Por exemplo, entre milhares de atividades do site eu preciso autenticar um CNPJ. Posso fazer uma função para fazer isso e chamá-la quando for necessário.
Reutilização do Código : Uma vez feita e testada a rotina ela poderá ser agrupada numa biblioteca ou módulos de funcionalidades e utilizada futuramente em outros projetos. Digamos que precisaremos programar e testar apenas uma vez o código...uma boa vantagem sobre um novo código.
Divisão de tarefas complexas em processos extremamente simples : Toda tarefa pode ser dividida em partes até que se torne tão simples que não dê mais para dividir em outras rotinas. Então desenvolvemos essas rotinas pequenas e simples (como testar uma data, CPF, CNPJ etc.) e criamos outras rotinas agrupando essas rotinas mais simples da maneira que queremos e essa 'rotina mais complexa' que agrupa um conjunto de rotinas simples já executa uma tarefa do sistema, como a autenticação de um usuário no site.
Simplificação de processo : Se você tem uma função que valida a data você fabricaria outra função para verificar data ? Claro que não. E se você precisar chamar uma vez ou um milhão de vezes teria impacto na memória ou encavalaria o processamento? Não, o módulo é carregado apenas uma vez e se se for chamada um milhão de vezes o processo de controle colocaria todos eles numa fila e processaria um de cada vez. Não haveria uma 'cópia multipla' da funcionalidade na memória ou no sistema e este é um ponto importante sobre a vantagem sobre o programa tipo OOP. Digamos que só há uma 'instância' do código na memória para atender a todos.
Se fosse definir o objetivo da linguagem programação procedural diríamos que é a implementação de procedimentos. Se a gente já tem um monte de procedimentos pré-definidos em bibliotecas fica muito facil desenvolver sistemas com esta metodologia.
Infelizmente não há como separar o que o sistema precisa do que o que ele não precisa. Por exemplo, se fiz uma biblioteca com 10 funcionalidades e o sistema esta usando somente 2 ou eu removo as 8 não necessárias ou elas serão carregagas e processadas como parte do sistema. É um desperdício de memória e processamento mas dependendo do sistema é irrelevante. Por exemplo, ao inserirmos o bootstrap em nossos sites não temos como inserir só uma parte do mínimo, só o mínimo completo mesmo que a gente só use uma funcionalidade do bootstrap. Só que o bootstrap tem 50k de tamanho. O que isso impacta num site ou na frankia de transferencia de dados de um celular ? Praticamente nada.
OOP significa que tudo que o sistema tem que trabalhar no mundo real tem uma representação no sistema. Por exemplo, se preciso cadastrar clientes terei um objetos clientes no meu programa. Se tenho uma Nota Fiscal terei que ter um objeto NotaFiscal. Ai podemos criar relacionamentos que definem, por exemplo, que para inserir uma Nota Fiscal no sistema o cliente precisa estar cadastrado antes. E ai a complexidade vai subindo quanto mais 'entidades' ou 'objetos' temos em nosso sistema.
Como cada 'entidade' do mundo real tem seu 'objeto' no sistema que o representa fica bem intuitivo criar funcionalidades, propriedades, métodos, parâmetros para o objeto. Pura similaridade. Por exemplo, estou vendendo carros quais os parâmetros importantes que devo armazenar ? Marca, Modelo, Ano, Kilometragem. Fica fácil saber o que precisa ser feito porque temos um exemplo do mundo real.
Do mesmo jeito que na linguagem procedural podemos colocar nossas funcionalidades em 'bibliotecas de classe'
que agrupariam as funcionalidades do sistema. Ao precisar das funcionalidades de uma biblioteca basta incluir
ela no nosso sistema e instanciar seus objetos na memória pela palavra 'NEW'
Importante : A 'biblioteca de classes' seria a receita do bolo e a instanciação da mesma seria o bolo em sí,
ou seja, a 'biblioteca de classes' é um modelo e a instânciação é o objeto em sí.
Desperdício de memória e processador : Sempre que você utiliza o 'NEW' para instanciar uma classe você pede ao sistema que aloque memória, execute o módulo construtor, etc. Isto tem um custo. O problema é que se dois processos precisarem da mesma 'classe' você teria 2 cópias dos objetos na memória com o gasto de cpu e tudo mais. Se houver 3 processos que utilizem a mesma classe você teria 3 cópias do mesmo objeto. E se for recursivo? Aí daria nó no pingo d´agua.
A execução de uma aplicação orientada a objetos tende a ser mais lenta que a procedural ou estruturada porque envolve alocação de memória, execução dos métodos construtores sempre que a classe for instanciada.
O conceito de POO é bem mais complexo que o procedural além de muitas vezes ser necessário escrever mais código como os métodos getters e setters dos objetos.
Se fossemos definir um objetivo para OOP diríamos que POO define classes que virtualizam objetos contudo pelo 'método OOP' leva em conta os comportamentos ou métodos , parâmetros ou características dos objetos.
Tem analistas que se dão muito bem com o desenvolvimento procedura de sistema e outros com o desenvolvimento Orientado a Objetos (OOP). Sempre use o que você consegue obter maior produtividade.
Só não afirme que este é melhor e este é pior porque isso não existe e demonstraria falta de conhecimento sobre o assunto. Citando um exemplo, em sua opinião qual é a melhor base de dados : Oracle. MS SQL Server, MySQL ou Maria DB, Postgre ? Se responder que uma delas é a melhor está errado. Cada uma delas se dá melhor em um determinado cenário. Porque o Fusca vendeu mais que o Corola no Brasil ? Fusca é melhor que o Corola ? Não, porque foi mais adequado as necessidades brasileiras. E é sempre assim, se você pudesse andar com uma Ferrari porque anda com um Fiat Uno ? Porque é o que a sua realidade financeira é o que permite.
O tamanho da aplicação normalmente define qual a metodologia a ser usada. Se for meia dúzia de páginas utilize a procedural e se forem muitas páginas use a OOP mas isso é apenas um conselho, não uma regra.
Se a melhor ferramenta que você conhece é um martelo você tende a ver todos os seus problemas como pregos. Verdade seja dita tem gente que foi adestrada a desenvolver de uma maneira e só sabe desenvolver dessa maneira. É como o grande mestre da cozinha francesa que ao trocar a panela ele queima até o arroz. Isso revela inexperiência.
Utilize a ferramenta de acordo com o que ela foi feita para desenvolver e não invente a roda porque o resultado sempre será péssimo. Peguei um sistema em VB6 (aplicação Desktop) que deveria migrar para web. O sistema só recebeu elogios de todos pela sua implementação.
Contudo sou um especialista e consigo ver a porcaria que fizeram. Conseguiram implementar OOP em um sistema desenvolvido em VB6. Falando a verdade, uma obra de arte a não ser pelo custo porque fizeram malabarismos para isso dar certo e o desenvolvimento ficou meio 'engessado' por esse 'modelo' de desenvolvimento.
Quanto a migração para web devido ao fato de usar OOP em uma linguagem que não é OOP deu nó em alguns pontos. Por exemplo, VB6 admite array de controles (o que é uma característica exclusiva de linguagens procedurais) enquanto VBNET e C# nem de longe permitem arrays de controles. Neste caso o jeito foi reescrever um monte de código por causa do devaneio dos analistas do projeto original.